This section details on the original issue you should resolve

<issue_title>[Safe Outputs Conformance] SEC-003: Max limit enforcement check produces 198 false positives due to overly broad scope and unrecognized enforcement pattern</issue_title>
<issue_description>### Conformance Check Failure

Check ID: SEC-003
Severity: MEDIUM
Category: Security / Check Design

Problem Description

The SEC-003 check in scripts/check-safe-outputs-conformance.sh currently flags 198 files as potentially not enforcing max limits. This high count is caused by two compounding issues:

1. Overly broad file scope: The check iterates over all *.cjs files in actions/setup/js/, which includes fuzz test harnesses, utility modules, sanitizers, MCP transport files, constants, and other non-handler files that have no responsibility for enforcing max limits.

2. Unrecognized enforcement pattern: The project's actual max limit enforcement is implemented via enforceArrayLimit() and tryEnforceArrayLimit() in actions/setup/js/limit_enforcement_helpers.cjs. The SEC-003 check pattern (\.length.*>.*\.max\|enforceMaxLimit\|checkLimit\|max.*exceeded) does not match these function names, so any handler that correctly delegates to the shared limit_enforcement_helpers.cjs module is still flagged.

The result is that the check cannot distinguish files that correctly use the shared enforcement helper from files that genuinely lack any limit enforcement. This makes the check ineffective for its intended security purpose.

Affected Components

• Check script: scripts/check-safe-outputs-conformance.sh (lines 106–123, check_max_limits function)
• Enforcement module: actions/setup/js/limit_enforcement_helpers.cjs (exports enforceArrayLimit, tryEnforceArrayLimit)
• Flagged files (sample): All 198 files in actions/setup/js/ excluding those matching test|parse|buffer|factory — including utility, sanitizer, MCP transport, fuzz harness, and message files

Current Behavior

# Check incorrectly flags all non-excluded .cjs files:
for handler in actions/setup/js/*.cjs; do
    [[ "$handler" =~ (test|parse|buffer|factory) ]] && continue
    if ! grep -q "\.length.*>.*\.max\|enforceMaxLimit\|checkLimit\|max.*exceeded" "$handler"; then
        log_medium "SEC-003: $handler may not enforce max limits"
    fi
done

Files that correctly require('./limit_enforcement_helpers') and call enforceArrayLimit() are still flagged because the grep pattern does not recognize those function names.

Expected Behavior

The SEC-003 check should:

1. Only target files that are actual safe output handlers (e.g., files that make GitHub API calls via octokit).
2. Recognize the project's standard enforcement functions: enforceArrayLimit, tryEnforceArrayLimit, as well as any require.*limit_enforcement_helpers import.

Remediation Steps

This task can be assigned to a Copilot coding agent with the following steps:

1. Scope the check to only files that actually perform GitHub API operations. A reliable proxy: files that contain octokit. calls (consistent with how SEC-002 scopes its check).
2. Update the grep pattern to include the project's actual enforcement functions:

   grep -qE "\.length.*>.*\.max|enforceMaxLimit|checkLimit|max.*exceeded|enforceArrayLimit|tryEnforceArrayLimit|limit_enforcement_helpers" "$handler"

3. Run the updated check and resolve any genuine remaining failures (files that perform API operations and do not use the shared enforcement helper for array parameters).

Verification

After remediation, verify the fix by running:

bash scripts/check-safe-outputs-conformance.sh

SEC-003 should report significantly fewer failures, limited to files with genuine missing enforcement.

References

• Safe Outputs Specification: docs/src/content/docs/reference/safe-outputs-specification.md
• Conformance Checker: scripts/check-safe-outputs-conformance.sh (lines 106–123)
• Limit Enforcement Module: actions/setup/js/limit_enforcement_helpers.cjs
• Run ID: §22281286232
• Date: 2026-02-22

Generated by [Daily Safe Outputs Confor...